All in all the PR LGTM, however I really wonder about some more recent design changes in the scale-info crate such as FormString and parameterizing PortableForm with a String type. Both of which do not really make a sense to me from an API design standpoint.

Codecov Report

Merging #663 (c6e35ce) into master (a8707cc) will decrease coverage by 15.83%.
The diff coverage is 73.33%.

@@             Coverage Diff             @@
##           master     #663       +/-   ##
===========================================
- Coverage   82.89%   67.05%   -15.84%     
===========================================
  Files         161      161               
  Lines        7389     7389               
===========================================
- Hits         6125     4955     -1170     
- Misses       1264     2434     +1170     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a8707cc...c6e35ce. Read the comment docs.

All in all the PR LGTM, however I really wonder about some more recent design changes in the scale-info crate such as FormString and parameterizing PortableForm with a String type. Both of which do not really make a sense to me from an API design standpoint.

See original rationale: paritytech/scale-info#35 (comment)

It's because substrate runtimes discourage use of String and to that end parity-scale-codec only support strings in std See https://github.com/paritytech/parity-scale-codec/blob/master/src/codec.rs#L357.

One idea I still need to investigate is the possibility of not storing the metadata in the runtime itself, but doing something similar to ink! where we generate the metadata up front using std. That would avoid the problem of having to support both & 'static str and String because we could just use std and String